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Abstract 


The  Information  Systems  Survivability  Assessment  (ISSA)  is  a  process  of  analytical  steps 
that  the  Survivability/Lethality  Analysis  Directorate  (SLAD)  of  the  U.S.  Army  Research 
Laboratory  (ARL)  applies  to  networked  Automated  Information  Systems  (INFOS  YS)  of  military 

interest. 

The  ISSA  Plan  for  a  particular  system  is  a  focused  plan  that  has  been  designed  to  provide  me 
decision-makers  the  necessary  information  with  which  to  make  informed  decisions  concerning 
the  vulnerabilities  and  susceptibilities  of  the  system  to  Information  Operations  (10)  threats.  The 
ISSA  is  a  multiple-phase  effort;  these  phases  are  intertwining  tasks.  Each  of  these  tasks  depends 

upon  the  others. 

The  plan  is  formulated  in  various  phases  to  help  the  decision-makers  modify  the  n^ess^ 
hardware  and  software  within  the  program  cycle  to  meet  the  necessary  survivability 
requirements.  The  ISSA  culminates  with  protection  measures  being  recommended  to  identify 
and  miniTniyft  the  impact  of  the  lO  threats  on  system  performance.  By  addressing  the  10  threats, 
the  system  will  significantly  improve  its  survivability  by  planning  for  both  the  avoiding  and 

withstanding  of  potential  problems  with  lO-based  threats. 

This  report  discusses  the  ISSA  process  in  detail  and  shows  how  each  small  task  dovetails  into 
the  larger  effort. 
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1.  An  Overview  of  Information  Systems  Survivability  (ISS) 


The  Information  Systems  Survivability  Assessment  (ISSA)  is  a  process  of  analytical  steps  that 
the  Survivability/Lethality  Analysis  Directorate  (SLAD)  of  the  U.S.  Army  Research  Laboratory 
(ARL)  applies  to  networked,  automated  information  systems  (INFOS YS)  of  military  interest. 
INFOSYS  are  defined  here  as  defined  in  both  Joint  Pub  6-0  [1]  and  FM  100-6  [2]. 

•  INFOSYS  from  Joint  Pub  6-0:  The  entire  infi-astructure,  organization,  personnel,  and 
components  that  collect,  process,  store,  transmit,  display,  disseminate,  and  act  on  information. 

•  INFOSYS  from  FM  100-6:  INFOSYS  allow  the  commander  to  view  and  understand  his  battle 
space,  communicate  his  intent,  lead  his  forces,  and  disseminate  his  pertinent  information 
throughout  his  chain  of  command  and  his  area  of  operation.  Effective  military  and  nonmilitary 
INFOSYS  help  the  staff  get  the  right  information  to  the  right  location  in  time  to  allow 
commanders  to  make  quality  decisions  and  take  appropriate  actions. 

This  discussion  focuses  primarily  on  the  ISS  as  defined  in  VAL-CE-TR-92-22  [3]. 

•  ISS  from  VAL-CE-TR-92-22:  The  ability  of  a  computer-communication-system-based 
application  to  continue  satisfying  its  requirements  (for  example,  requirements  for  security, 
reliability,  real-time  responsiveness,  and  correctness)  in  the  face  of  adverse  conditions. 

The  goal  of  SLAD’s  ISS  tools,  techniques,  and  methodology  (TTM)  development  program  is  to 
gaierate  predictive  computer  models  that  predict,  as  closely  as  is  reasonably  possible,  the  real- world- 
observed  behavior  of  specific  information  processor  properties  caused  by  various  real-world  stimuli 
using  an  agreed-upon  set  of  metrics.  These  stimuli  range  from  normal  network  operations  to  the 
stressing  stimuli  caused  by  various  software  errors,  hardware  errors,  and  the  multitude  of  the 
different  forms  of  intentional  or  unintentional  misuse  and  hostile  attacks  to  which  an  information 
processor  may  be  subjected. 
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Figure  1  [4]  shows  the  overall  schema  of  the  modeling  approach  that  will  be  taken  to  achieve 
this  goal.  Models  are  based  on  data  that  are  obtained  through  real-world  observations, 
measurements,  assumptions,  approximations,  and  predictions.  These  data  are  distilled  using  verified 
algorithms  into  model  parameters,  both  variable  inputs  and  fixed  coefficients.  The  modeler/analyst 
perceives  the  structure  of  real-world  events  and  converts  this  perception  to  a  symbolic 
representation,  through  the  use  of  a  computer  language,  into  a  computer  model.  Interpretation, 
verification,  and  modification  are  some  of  the  events  used  by  the  modeler/analyst  to  adjust  the 
symbolic  representation.  There  are  several  attributes,  which  the  modeler/analyst  can  possess,  that 
are  useful  in  balancing  the  observed  behavior  of  the  real  world  with  the  model  behavior.  These  are 
experience;  intuition;  and  a  knowledge  base  of  the  primary,  and  a  great  many  of  the  secondary, 
academic  disciplines.  These  disciplines  include  physics,  computer  science,  optics,  mathematics, 
statistics,  electronics,  etc. 
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Figure  1.  System  Modeling. 
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Classes  of  models  range  from  simple,  look-up  tables  (in  two  or  more  dimensions)  to  the  complex 
task  of  predicting  the  outcomes  of  live-fire  shoots.  Simulations  may  be  an  amalgamation  of 
numerous  individual  models  from  multiple  classes. 

Analyses  preformed  by  SLAD  are  concerned  with  an  extremely  broad  spectrum  of  threats.  The 
classification  of  these  threats  include  ballistic,  nuclear,  chemical,  electronic,  atmospheric,  and 
information  based.  SLAD  has  historical  backgrounds  in  all  of  these  threats.  The  information-based 
threats  are  relativity  new  threats  and  have  become  a  concern  with  the  advent  of  information 
processors  (computer  systems)  on  the  battlefield. 

An  element  of  SLAD’s  mission  is  to  conduct  integrated  analysis.  This  is  a  scenario-based 
analysis  containing  the  occurrence  of  two  or  more  separate  threats.  The  primary  guide  used  by 
SLAD  for  these  integrated  analyses  is  the  vulnerability/lethality  (V/L)  taxonomy.  This  V/L 
taxonomy  has  been  documented  and  enhanced  in  numerous  reports  [5-21]  and  is  depicted  in 
Figure  2.  As  pointed  out  in  Ruth  and  Hanes  [20],  the  integration  of  the  separate  threat  effects 
happens  in  the  V/L  taxonomy  with  the  mapping  between  level  2  (damage  state)  and  level  3 
(capability  state).  This  mapping  is  typically  performed  using  fault  trees.  For  the  integration  of 
separate  threat  analyses  to  be  successful,  the  desire  for  an  integrated  product  has  to  be  a  primary 
design  consideration  in  any  analytical  process.  Compatibility  and  conformance  with  the  SLAD- 
integrated  product  was  an  objective  motivating  the  design  of  the  SLAD  ISSA  presented  herein. 


2.  The  ISSA  Process 

The  ISSA  is  stractured  in  five  phases,  as  shown  in  Table  1.  Each  of  these  five  phases  has  its  own 
procedures  and  connects  to  the  following  phases  through  particular  products.  The  flow, 
interconnection,  and  the  products  passing  through  these  five  phases  are  shown  in  Figure  3. 
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Figure!.  The V/L Taxonomy. 

Figure  3  presents  a  wiring  diagram  that  depicts  the  interconnections  of  the  phases  of  an  ISSA. 
The  boxes  shown  internal  to  the  larger  boxes  are  products  of  that  particular  phase  of  the  analysis. 
The  arrows  that  connect  the  phases  show  how  products  of  one  phase  feed  into  the  other  phases  and 
then  permeate  the  entire  process.  Internal  to  the  process,  there  exist  multiple  feedback  loops  that 
are  not  shown  on  the  diagram.  Also,  each  of  these  phases  is  further  constructed  of  multiple  phases 
and  individually  tailored  for  the  system  under  analysis. 
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Table  1.  The  Five  Phases  of  an  ISSA 


Phase  Number 

Phase  Title 

1 
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2 

System  Design  Analysis 
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Figure  3.  Schematic  of  the  Methodology  Flow  of  an  ISSA. 


In  an  ISSA,  a  system  is  made  up  of  both  hardware  and  software.  These  pieces  are  further 
subdivided  into  components  and  subsystems.  These  are  defined  in  zum  Brunnen  [22]  as  follows; 
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“The  hardware  is  made  up  of  components,  subsystems,  and  systems.  A  component  is  an 
individual  item  such  as  an  integrated  circuit  (IC)  chip,  cable,  disk  platter,  cooling-fan 
blade,  printed  circuit  board,  etc.  A  subsystem  is  an  assemblage  of  components  or 
subsystems.  For  example,  a  disk  drive  is  a  subsystem'  it  is  constructed  from  motors, 
read/write  heads,  disk  platters,  cables,  IC  chips,  printed  circuit  cards,  etc.  To  further 
complicate  matters,  a  disk  drive  is  a  component  of  an  input/output  (I/O)  subsystem.  An 
I/O  subsystem  is  made  up  of  disk  drives,  printed  circuit  cards,  IC  chips,  cables,  data 
buses,  etc.  A  system  is  a  collection  of  subsystems.  Examples  of  subsystems  are  I/O, 
graphics,  memory,  power,  etc.” 

2.1  The  System  Familiarization  Phase.  The  system  familiarization  work  will  encompass  a 
review  of  system  documentation,  as  well  as  discussions  with  the  program  manager  (PM)  office  and 
its  contractors  to  gain  knowledge  or  data  concerning  the  system’s  mission  critical  INFOSYS 
resources,  both  hardware  and  software.  System  documentation,  including  the  required  operational 
capability  (ROC),  test  and  evaluation  master  plan  (TEMP),  operational  requirements  document 
(ORD),  prime  item  development  specification  (PIDS),  and  software  requirements  specifications 
(SRS),  will  be  reviewed  to  assimilate  the  various  mission-critical  INFOSYS  resources  into  a  single 
document. 

An  analysis  of  the  system  hardware  will  include  the  processors,  data  storage,  I/O,  and 
interconnections  between  the  subsystems,  as  well  as  the  system  and  other  external  interfaces.  This 
analysis  will  be  documented  as  the  system  architecture  portion  of  the  system  familiarization  phase. 
The  analysis  of  system  software  will  include  understanding  operating  systems,  network,  and 
application  programs.  An  overview  of  what  information  is  used,  where  it  is  used,  and  how  it  flows 
will  be  developed  and  documented.  This  analysis  will  be  documented  as  the  system  description 
portion  of  the  system  familiarization  phase. 

2.2  The  System  Design  Analysis  Phase.  As  shown  in  Figure  3,  this  phase  has  two  major 
subcomponents:  the  system  functionality  assessment  and  the  data  flow  analysis. 

2.2.1  The  System  Functionality  Assessment  As  the  name  implies,  this  is  an  assessment  of  the 
functionality  of  the  system.  This  assessment  is  done  from  the  INFOSYS  perspective  and  focuses 
on  the  mission-critical  INFOSYS  of  the  system.  The  goal  of  the  functionality  assessment  is  to 
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determine  if  the  system  can  achieve  its  specific  requirements  from  an  INFOSYS  perspective.  In  this 
assessment,  the  system  requirements  and  specifications  are  mapped  into  the  system  description  and 
system  architecture  produced  in  the  system  familiarization  phase  of  the  ISSA.  This  is  an  effort  to 
determine  if  the  requirements  and  specifications  laid  out  by  the  system  proponent  are  functionality 
obtainable  by  the  designed  system.  This  effort  focuses  on  the  INFOSYS  components  of  the  system 
and  is  not  concerned  with  items  such  as  ballistic  protection,  soldier  compatibility,  etc. 

2.2. 2  The  Data  Flow  Analysis.  This  overview  will  be  used  to  formulate  the  detailed  program 
specifications  for  an  information  flow  model  (BFM)  of  the  system  under  analysis.  These 
specifications  will  be  based  on  the  system  hardware,  software,  operating  systems,  protocols, 
topology,  and  interconnections  between  both  internal  subsystems  and  external  communications. 
This  phase  of  the  ISSA  uses  all  the  products  of  the  previous  phases.  The  system  description,  system 
architecture,  and  system  design  assessment  all  bring  critical  information  into  this  phase.  An  attempt 
will  be  made  to  reflect  the  system  security  policy  and  how  it  is  enforced.  The  IFM  is  meant  to 
provide  some  initial  analytical  measure  of  performance  of  the  system  for  different  configurations 
and  scenarios.  Possible  reported  performance  metrics  may  include  message  latency  and  error  rates 
vs.  network  load. 

The  data  flow  diagram  generated  will  be  documented.  This  documentation  will  be  in  the  form 
of  a  data  dictionary  and  transform  descriptions.  The  data  dictionary  documents  each  of  the  interface 
flows  and  data  stores  on  any  data  flow  diagram.  The  transform  descriptions  document  the  internals 
of  the  data  flow  diagram  processes  in  a  rigorous  fashion  (usually  through  the  use  of  structured 
English,  decision  tables,  and  decision  trees).  For  further  details  on  data  flow  diagrams,  data 
dictionaries,  and  transform  descriptions,  see  DeMarco  [23]. 

The  data  flow  diagram  will  be  developed  into  a  simulation  using  available  modeling  tools 
(e.g.,  an  operational  network  [OPNET]  simulation).  This  simulation  will  allow  the  behavior  of  the 
system’s  data  flow  through  hardware  components,  software  components,  protocols,  and  interfaces 
to  be  studied  in  detail. 
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2.3  The  Threat  Definition  and  Assessment  Phase.  The  System  Threat  Assessment  Report 
(STAR)  for  the  system  will  be  reviewed  for  inclusion  of  current  and  future  I/O  specific  threats,  their 
mechanisms,  or  procedures.  All  available  and  relevant  sources  of  threat  information  will  be  utilized 
during  this  threat  definition  phase.  Relevant  information  will  be  leveraged  to  the  greatest  extent 
possible.  To  include  both  traditional  and  nontraditional  sources  (e  g..  Federal  Bureau  of 
Investigation  [FBI],  National  Security  Agency  [NSA],  Defense  Intelligence  Agency  [DIA], 
Computer  Emergency  Response  Teams  [CERTs],  Central  Intelligence  Agency  [CIA],  bulletin 
boards,  Hacker  publications,  etc.).  The  system’s  INFOSYS  environments,  from  manufacturing, 
storage  at  the  depot  and  on  to  deployment,  will  also  be  addressed  during  this  investigation.  The 
classes  of  possible  threats  are  defined  as; 

•  destruction  of  the  system, 

•  interruption  of  service, 

•  removal  or  loss  of  information, 

•  disclosure  of  sensitive  or  classified  information,  and 

•  information  corruption. 

The  threat  assessment  phase  is  critical  in  supporting  the  PM  by  ensuring  that  only  relevant 
threats  are  included  in  the  ISS  A.  An  update  to  the  STAR  will  be  accomplished  by  working  with  the 
appropriate  threat  working  groups  to  ensure  that  relevant  I/O  threats  are  considered  and  understood. 
One  of  the  products  of  the  threat  definition  and  assessment  will  be  a  threat  susceptibility  analysis. 
In  this  analysis,  both  the  likelihood  of  occurrence  of  a  given  threat  and  the  potential  susceptibility 
of  the  INFOSYS  components  of  the  system  need  to  be  determined.  The  threats  to  which  the  system 
has  been  determined  to  be  susceptible  are  then  reexamined,  and  the  individual  threat  functioning 
mechanisms  are  analytically  “played”  against  the  information  flow  model  specification  (list  of 
equipment,  connections,  etc.)  that  was  made  during  the  system  familiarization  phase  of  this  ISSA. 
The  result  of  this  anal5dical  play  become  one  element  of  the  vulnerability  assessment.  Only  threats 
to  which  the  system  component(s)  are  susceptible  need  to  be  considered  in  further  vulnerability 
assessments. 


a 


2.4  The  Vulnerability  Assessment  Phase.  The  vulnerability  assessment  phase  is  broken  into 
two  pieces; 

(1)  analytical  and 

(2)  experimental. 

2.4.1  The  Analytical  Vulnerability  Assessment  Given  the  combined  use  of  the  system, 
description  and  architecture,  the  system  design  assessment,  and  the  threat  definition  and 
susceptibility  analysis,  an  analytical  list  of  causes  and  effects  are  generated. 

Consider  the  following  example; 

•  within  system  C,  if  protocol  X  is  used  to  send  a  particular  packet  of  size  E  bits  from 
component  A  to  component  B,  and 

•  if  the  packet  receive  buffer  in  component  B  is  of  size  D  bits,  and 

•  if  D  (the  buffer  size  in  bits)  is  smaller  than  E  (the  packet  length  in  bits)  or  D  <  E. 

The  resulting  event  (in  the  case  of  this  example,  buffer  overflow)  can  be  predicted.  With  some 
degree  of  experience  the  analyst  can  than  predict  the  result  of  this  event  (in  this  example,  buffer 
overflow),  the  likelihood  of  this  event,  and  the  degree  to  which  it  could  possibly  affect  the  ability 
of  the  system  to  complete  its  mission. 

2.4.2  The  Experimental  Vulnerability  Assessment  The  system  (as  constructed  in  the  I/O 
laboratory,  either  real  or  surrogate)  is  then  subjected  to  a  suite  of  laboratory  experiments  that  is 
modeled  after  the  prioritized  list  vulnerabilities  generated  in  the  analytical  portion  of  this  phase. 
The  predicted  results  of  the  analytical  portion  will  then  be  either  confirmed  or  negated. 

The  laboratory  experiments  will  also  yield  data  upon  which  I/O  algorithms  can  be  based.  These 
algorithms  will  then  be  incorporated  into  the  data  flow  modeling  of  the  system  being  done  in  the 
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system  design  analysis  portion  of  the  ISSA.  The  algorithms  and  resulting  models  are  then  added 
to  the  common  library  of  data  flow  tools  for  use  in  future  ISSAs. 

2.4.3  Vulnerability  Assessments  in  GeneraL  The  methodology  used  in  the  assessment  must 
be  robust  enough  to  adequately  address  the  balance  between  the  equally  important  component 
vulnerabilities:  the  likelihood  of  occurrence  and  the  effectiveness  severity  given  this  occurrence. 
This  balance  can  be  achieved  by  taking  a  product  of  these  two  probabilities.  One  method  of 
performing  an  assessment  is  detailed  in  Guzie  [24] .  The  probabilities  of  occurrence  used  here  were 
previously  determined  during  the  threat  assessment  and  definition  phase  of  the  ISSA.  The 
determination  of  effectiveness  severity,  given  the  occurrence  of  the  threat,  is  the  bulk  of  the  effort 
during  this  phase. 

Software  issues  focus  on  threats  that  originate  in  software.  Generally,  software  threats  can  be 
lumped  into  two  categories:  accidental  and  malicious.  When  damage  occurs  by  accident,  the  code 
involved  is  termed  a  software  bug.  This  bug  may  have  been  caused  by  programmer  error,  the 
resulting  actions  of  the  bug  were  totally  unintentional.  Bugs  are  perhaps  the  most  common  cause 
of  unexpected  program  behavior. 

Opposed  to  the  unintentional  results  of  software  bugs  are  the  intentional  results  of  the  malicious 
codes  or  programmed  threats.  These  threats  are  built  with  deliberate  instructions  by  individuals  who 
intend  for  abnormal,  and  often  damaging,  behavior  to  occur. 

Two  of  the  many  potential  risks  that  require  assessment  during  an  ISSA  are  those  from  threats 
posed  by  malicious  codes  and  hostile  intrusions.  It  needs  to  be  noted  that  an  ISSA  is  not  limited 
only  to  threats  from  malicious  codes  and  hostile  intrusions.  These  two  threats  cut  across  many  of 
the  system  properties  that  are  assessed  in  an  ISSA.  Namely,  these  are  system  integrity,  system 
availability,  system  confidentiality,  authorization  and  accountability  of  systems  and  users,  data 
integrity,  data  availability,  data  confidentiality,  and  functional  correctness. 
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2.5  The  Protection  Assessment  and  Recommendations  Phase.  This  is  an  effort  to  formally 
present  measures  that  may  be  taken  to  protect  the  system  under  analysis  from  the  potential  threats 
identified  during  the  threat  definition  and  assessment  phase.  These  measures  may  include  items 
such  as  developed  or  modified  malicious  code  or  intrusion  indications  and  warnings  devices  or 
software  (these  are  I/O  tools)  configured  for  the  system.  The  validation  and  verification  for  the 
proper  utilization  of  these  tools  (devices  or  software)  is  done  by  installing  them  on  the  system  (real 
or  surrogate)  as  configured  in  the  I/O  laboratory  and  applying  the  predicted  threats  to  the  system. 

3.  The  Relationship  of  the  ISSA  Process  to  the  V/L 
Taxonomy 


Throughout  the  individual  phases  of  an  ISSA,  the  behavior  or  state  of  various  INFOS YS 
properties  are  analyzed.  Table  2  presents  the  definitions  of  these  various  properties  as  per 
VAL-CE-TR-92-22  [3]. 

As  previously  stated,  the  V/L  taxonomy  is  the  guide  used  by  SLAD  for  integrated  analyses.  The 
V/L  taxonomy  presents  a  structured  approach  for  taking  threat  effects  and  progressing  through  a 
series  of  mappings  to  produce  a  platform  battlefield  utility.  This  structure  is  shown  in  Figure  2. 

The  threats  of  concern  in  an  ISSA  is  I/O  based.  Therefore,  one  of  the  purposes  of  an  ISSA  is 
to  map  the  effects  resulting  from  an  I/O-based  threat  event  to  a  platform  battlefield  utility.  The 
mappings  will  primarily  be  functions  of  computer  science  (e.g.,  network  theory,  computer 
engineering,  etc.),  communications,  and  electronics.  The  individual  component  level  effects  will 
primarily  be  seen  as  computer  science  types  of  effects.  These  component  level  effects  will  further 
cause  effects  as  a  result  of  networking  and  communications  within  the  platform  (or  system).  Table  3 
presents  a  sample  breakout  of  INFOS  YS-related  metrics  (properties  that  can  be  measured)  as  a 
function  of  V/L  taxonomy  level.  The  example  metrics  used  in  Table  3,  for  V/L  taxonomy  levels 
2  and  3,  are  the  various  INFOSYS  properties  that  are  presented  in  Table  2. 
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Table  2.  Various  INFOSYS  Properties  and  Definitions 


Property 

Definition 

System  Integrity 

The  system’s  ability  to  prevent  malicious  (and,  to  some  extent, 
accidental)  effects  on  the  hardware,  system  software,  and 
intercommunications . 

System  Availability 

The  system’s  ability  to  prevent  system  and  communication  outages, 
including  temporary  unavailability  of  resources.  Such  outages  may 
include  malicious  or  accidental  denials  of  system  service. 

System  Confidentiality 

The  system’s  ability  to  prevent  the  imdesired  dissemination  or 
acquisition  of  sensitive  system  code  or  data,  particularly  if  the 
application  can  be  compromised;  otherwise,  for  example,  knowledge 
of  the  system  design,  a  specific  algorithm,  a  piece  of  code,  a  password, 
a  cryptographic  key,  a  network  authenticator,  or  a  piece  of  equipment 
could  lead  to  a  system  subversion. 

Authorization  and 
Accoimtability  of 

Systems  and  Users 

A  system’s  is  capability  to  control  which  subsystems  and  individuals 
are  using  it;  otherwise,  it  may  be  vulnerable  to  spoofing  attacks, 
penetrations,  and  other  forms  of  misuse.  After  any  such  attack,  the 
system’s  inability  to  provide  real-time  (or  at  least  rapid)  accountability 
and  audit-trail  analysis  may  lead  to  additional  compromises  of 
survivability. 

Data  Integrity 

The  system’s  ability  to  prevent  undesired  alteration  of  input  data, 
internal  stored  data,  or  ouq)ut  data.  Data  integrity  includes  internal 
data  consistency  (particularly  important  in  a  highly  dispersed 
environment),  as  well  as  external  consistency  with  the  real  world. 

Data  Availability 

The  system’s  ability  to  prevent  disruption  in  timely  access  to  data, 
including  sensor  data  in  a  control  system.  Multiple  versions  of  critical 
data  and  alternative  sensors  can  help  increase  data  availability. 

Data  Confidentiality 

The  system’s  ability  to  prevent  xmdesired  data  disclosure.  For  example, 
a  penetrator  could  obtain  sensitive  data  that  would  compromise  the 
application’s  ability  to  fulfill  its  requirements. 

Fault  Tolerance 

The  system’s  ability  to  prevent  undesired  effects  resulting  firom  failure 
of  underlying  hardware  components,  subsystems,  or  indeed  the  entire 
system.  !^sentially,  fault  tolerance  is  both  a  system  integrity  issue  and 
a  system  reliability  issue.  Constructive  use  of  redundancy  is  essential. 
Survivability  is  a  particular  concern  when  the  nominal  fault  tolerance 
coverage  is  expected. 
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Table  2.  Various  INFOSYS  Properties  and  Definitions  (continued) 


Property 

Definition 

Functional  Correctness 

Assurance  that  a  flaw  in  the  application  or  in  the  computer  operating 
system  or  a  human  error  in  system  maintenance  cannot  compromise 
the  application.  Good  software  engineering,  development  practices, 
and  system  operation  are  important  but  are  clearly  not  enough  by 
themselves. 

Real-Time  Availability 

Assurance  that  the  real-time  processing  can  be  done  in  a  timely  way, 
and  that  the  system  is  protected  against  maliciously  or  accidently 
caused  delays.  This  property  includes  the  real-time  availability  of  the 
system,  data,  and  other  resources. 

Real-Time 

accountability 

Such  as  anomaly  detection  and  audit-trail  analysis. 

Timely  Detection  and 
Correction  of  Deviant 
System  Behavior 

The  ability  of  the  system  to  reconfigure  itself  in  the  face  of 
nontolerated  faults  or  penetrations.  Recovery  from  serious  outages 
may  or  may  not  be  allowed  to  incur  long  time  delays  or  human 
intervention.  In  cases  where  human  intervention  is  not  possible, 
thorough  advanced  planning  is  necessary. 

Functional  Timeliness 

Such  as  strict  bounds  in  hard  real-time  systems  or  best-effort  intentions 
in  fuzzy  real-time  systems. 

1 

Ability  to  Mamtam 
Minimum  Essential 
System  Requirements 

The  system’s  ability  to  conduct  operations  in  the  presence  of 
unforeseen  adverse  conditions.  This  also  involves  the  establishment 
of  the  minimum  operating  requirements.  The  user  of  the  system 
generates  these  requirements  based  on  the  minimum  system 
j^ctionality  needed  to  complete  mission  requirements. 

One  of  the  goals  of  SLAD’s  I/O  mission  area  is  to  robustly  address  the  class  of  questions  such 
as  the  following. 

•  How  does  data  integrity  (at  V/L  level  2)  relate  to  reliability  (at  V/L  level  3)? 

*  Given  this  relationship,  how  then  does  reliability  (at  V/L  level  3)  relate  to  acquisition  (at  V/L 
level  4)? 
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Table  3.  A  Sample  Breakout  of  INTOSYS-Related  Metrics  to  V/L  Taxonomy  Levels 


V/L  Taxonomy  Level 

Example  Metrics* 

Sample  Level  2  Metrics 

•  System  integrity 

(Damage  States) 

•  System  availability 

[System,  Subsystem,  or 

•  System  confidentiality 

Component] 

•  Authorization  and  accountability  of  systems  and  users 

•  Data  integrity 

•  Data  availability 

•  Data  confidentiality 

•  Fault  tolerance 

•  Functional  correctness 

•  Real-time  availability 

•  Real-time  accountability 

Sample  Level  3  Metrics 

•  Timely  detection  and  correction  of  deviant  system  behavior 

(Capability  States) 

•  Functional  timeliness 

[System,  Subsystem,  or 

•  Ability  to  maintain  minimum  essential  system  requirements 

Component] 

•  Reliability 

•  Maintainability 

•  Supportability 

•  Range  and  accuracy 

•  Speed  of  performance 

Sample  Level  4  Metrics 

•  Mobility 

(Battlefield  Utility) 

•  Firepower 

[Platform] 

•  Acquisition 

•  Crew 

•  Communication 

•  Other 

*  Here,  the  term  “System”  refers  to  “Information  Systems.” 


The  interrelationships  between  the  properties  (or  metrics)  are  nontrivial  and  require  a  large 
consolidated  effort  to  tmderstand,  analyze,  and  model. 


4.  Summary 


The  system  ISSA  plan  is  a  focused  plan  to  provide  the  decision  makers  with  the  necessary 
information  with  which  make  informed  decisions  concerning  the  vulnerabilities  and  susceptibilities 
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of  the  system  to  FO  threats.  The  associated  research  and  analyses  are  performed  by  a  team  of  people 
who  are  knowledgeable  in  the  various  required  FO  areas. 

The  multiple  phases  of  the  effort  should  not  be  considered  separate,  stand-alone  tasks.  These 
phases  are  intertwining  tasks.  Each  of  these  tasks  depends  upon  the  others.  For  example,  during  the 
system  familiarization  phase,  the  specifics  that  will  drive  the  EFM  specifications  are  determined  (i.e., 
the  identification  of  the  specific  types  of  machines,  network  modules,  physical  configurations,  and 
particular  protocols  used  in  the  system).  These  same  specifics  will  determine  some  of  the  particular 
threat  susceptibilities  examined  in  the  threat  assessment  and  definition  phase. 

The  system  design  analysis  phase  will  clarify  questions  that  come  up  during  the  system 
familiarization  phase  and  will  feed  the  threat  assessment  and  defimtion  phase.  As  an  example,  how 
is  module  A  connected  to  module  B  (cable  and  connector  type,  etc.),  what  communications  protocols 
are  used  to  manage  this  link,  and  what  is  the  data  transmission  rate  of  this  link.  While  there  are 
separate  phases  of  work  being  discussed,  in  practical  application,  they  are  a  single,  large, 
interconnected  effort. 

The  system  ISSA  will  identify,  specify,  and  inform  decision  makers  of  the  system’s 
vulnerabilities  to  FO-based  threats.  Protection  measures  will  be  recommended  to  identify  and 
minimize  the  impact  on  system  performance.  The  plan  is  formulated  in  various  phases  to  help  the 
decision  makers  modify  the  necessary  hardware  and  software  within  the  program  cycle  to  meet  the 
necessary  survivability  requirements.  By  addressing  the  FO  threats,  the  system  will  sigmficantly 
improve  its  survivability  by  planning  for  both  the  avoiding  and  withstanding  of  potential  problems 
with  FO-based  threats.  Avoiding  these  problems  will  allow  the  system  to  effectively  contribute 
during  combat  on  the  future  battlefield. 


Intentionally  left  blank. 
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